Skip to main content

Intro

In this tutorial, follow the steps below to set up your builds to send test results and coverage files (optionally) to BuildPulse to help you identify and eliminate flaky tests.

If you'd like help at any step, please get in touch.

If you haven't already done so, set up a reporter to output XML reports for your test results.

You can see end-to-end examples for various test frameworks here, including RSpec, Cypress, Go, and others.

If you don't see your test framework listed, please get in touch. We can usually publish an example for a new test framework within a few days.

Natively Supported CI Providers

BuildPulse supports all continuous integration providers. We have native integrations/plugins that allows us to infer the necessary configuration from your CI provider's environment variables.

We natively support:

Other CI Providers

If you're using a CI provider that isn't listed above (Azure DevOps, AWS, TeamCity), you can still use BuildPulse. You'll need to add a few lines of configuration to your build.

What is a CI Provider?​

Continuous integration (CI) is an process or workflow that performs application builds and automated testing. These builds are usually scheduled after a source code change/pull request//n is merged in, or on a periodic basis - this task is usually managed by the devops or infrastructure team. Example tasks in a build are compiling and testing an application, or build a docker image to send to a repository.

CI is an integral aspect of modern software development and provides real-time feedback to development teams. They can even perform continuous delivery, serving both ci/cd pipelines for shipping new code. A CI Provider is a managed automation service that hosts the infrastructure and provides guardrails/functionality for configuring your own workflow.